Mobile IP (or IP mobility) is an Internet Engineering Task Force (IETF) standard communications protocol that is designed to allow mobile device users (or mobile nodes) to move from one network to another while maintaining a permanent IP address. Mobile IPv6 is a version of Mobile IP which enables a mobile node (MN) to maintain its connectivity to a packet data network (e.g., the Internet) during handover—e.g., when moving from one access network to another access network.
RFC 3775, “Mobile Support in IPv6” (which is incorporated herein by reference), describes techniques that enable a mobile node to remain reachable while the mobile node roams on the Internet. However, the location and movement of the mobile node can be revealed by IP addresses used in packets. IP address location privacy is concerned with unwittingly revealing the current location of a mobile node to eavesdroppers and to communicating parties. In the presence of mobility as defined in RFC 3775, there are two related aspects: disclosing the care-of address to a correspondent node (CN), and revealing the home address to an eavesdropper. A detailed description of the location privacy problem can be found in RFC 4882 (which is incorporated herein by reference).
In order to protect location privacy, a mobile node must not disclose the binding between its care-of address and its home address. Another issue related to IP address location privacy is “profiling”, where the activities of a mobile node are linked and then analyzed. Profiled activities may contribute to compromising the location privacy of a mobile node, especially when combined with additional information. Furthermore, once location privacy is compromised, it may lead to more targeted profiling.
IRTF draft, “Mobile IPv6 Location Privacy Solutions”, draft-irtf-mobopts-location-privacy-solutions-09, http://tools.ietf.org/id/draft-irtf-mobopts-location-privacy-solutions-09.txt, proposes some conventional location privacy solutions. The following is a list of key points:
1) A routable pseudo home address is as follows: pseudo home address=one of home network prefixes∥Enc(Kph, interface ID), where Enc(.) can be either a block cipher or a stream cipher.
During the home binding update between the mobile node and the home agent with the IPsec transport mode, the binding update message appears as follows:                IPv6 header (source=care-of address, destination=home agent)        Destination option header                    Home Address option (pseudo home address)                        ESP header in transport mode        Mobility header                    Home Binding Update            Alternative Care-of Address option (care-of address)                        
The home agent replies to the mobile node with the Binding Acknowledgement (BA) which contains the pseudo home address in the Type 2 Routing Header.
2) The return routability procedure and the correspondent registration procedure are as follows.
When initiating the communication with its correspondent node, the mobile node sends a Home Test Init (HoTI) message to its home agent in the following format:                IPv6 header (source=care-of address, destination=home agent)        ESP header in tunneling mode        IPv6 header (source=pseudo home address, destination=correspondent node)        Mobility header                    HoTI                        
The mobile node sets a ‘Q’ bit in the reserved field of the HoTI message 100 shown in FIG. 1 to indicate that it uses a pseudo home address generated by cryptography in place of the home address. The home agent processes the received HoTI message in a similar way as described in RFC 3776 (which is incorporated herein by reference). The home agent derives the real home address by using the pseudo home address as a key to look up its binding cache and verify the SPD using the real home address as one of the selectors. Subsequently, the home agent forwards the HoTI message with pseudo home address as source IP address to the correspondent node.
The correspondent node processes this received HoTI message (using the pseudo home address as the value for the otherwise present home address) in the same way as described in RFC 3775 and sends the HoTI message addressed to the pseudo home address towards the home agent. If the ‘Q’ bit is set, the correspondent node sets a corresponding ‘Q’ bit in the HoTI message. This allows the home agent to determine that pseudo home address is present. Since the pseudo home address is routable, the HoTI message is forwarded to the home network and intercepted by the home agent. Upon reception, the home agent uses the pseudo home address as a key to look up its Binding Cache which returns the real home address of the mobile node. Then the home agent uses the corresponding security association to process and forward the HoTI message to the home address of the mobile node.
The care-of address test is exactly the same as specified in RFC 3775.
After receiving both HoTI and CoT messages, the mobile node first computes the binding management Kbm using the care-of keygen token and the home keygen token (which itself is computed using the pseudo home address). The Binding Update has an additional field: Enc(Kbm, invariant-pseudo-HoA), where invariant-pseudo-HoA is the very first pseudo home address used with the particular correspondent node. This is necessary because the pseudo home address keeps changing, and session continuity needs to be secured. In other words, the invariant address seen by the upper layer protocols at the correspondent node is invariant-pseudo-HoA at all times. The rest of the fields in the Binding Update is the same as described in RFC 3775.
FIG. 2 illustrates an Encrypted invariant-pseudo-HoA option 200. After receiving the Binding Update, the correspondent node first computes the home keygen token and the care-of keygen token, then computes Kbm and verifies the MAC. If the MAC is valid, the correspondent node keeps the pseudo home address and the invariant-pseudo-HoA in the Binding Cache. The correspondent node then generates a Binding Acknowledgement and sends the Binding Acknowledgement back to the pseudo home address of the mobile node.
The subsequent data traffic between the mobile node and the correspondent node will follow the same procedure and the packet formats as specified in RFC 3775 except that the pseudo home address is used in place of the home address. And, equally importantly, the correspondent node presents the invariant-pseudo-HoA to the upper layers.
There are some flaws in the solutions above.
In 1) above, first, although the pseudo home address can be generated by concatenating one of home network prefixes and Enc(Kph, interface ID). However, there is no solution to inform the mobile node any new home network prefix that is different from the one used by the mobile node to form its home address. Second, the home network prefix is still in clear when used in the home registration procedure, therefore, eavesdroppers on the path between the mobile node and the home agent can profile activities based on the home network prefix and even identify the mobile node if the home network prefix is unique to each mobile node (this is the case when the link between the mobile node and the home agent is the point-to-point link). Third, in the binding update message, there is no any indication that a pseudo home address is used instead of the real home address, because the pseudo home address is carried in the home address destination option. Furthermore, the mobile node cannot inform the home agent that it wants to use the location privacy solution. On the other hand, in the binding acknowledgement sent back from the home agent to the mobile node, there is no indication in the Type 2 Routing Header showing that the home agent processes the binding update based on the pseudo home address; it is possible that the mobile node knows that by comparing the IP address in the Type 2 routing header with the previously used pseudo home address; however that is not good for packet processing. More importantly, there is no way for the home agent to tell the mobile node whether the home agent supports the location privacy solutions or not.
In 2) above, first, the pseudo home address is used as the source IP address in the inner header of the HoTi message sent from the mobile node to the home agent. However, this requires the changes of IPSec because the SPD entry is set up with the mobile node's real home address instead of the pseudo home address. Second, the Encrypted invariant-pseudo-HoA option is used to indicate the invariant-pseudo-HoA to the correspondent node and a different pseudo home address is used in the return routability procedure to generate a new home keygen token. This solution does not test the reachability of invariant-pseudo-HoA, which results in new vulnerabilities, for example, eavesdroppers can intercept the traffic to a mobile node.